As described in US patent application publication number 2007/0253446 and incorporated herein by reference; multilink protocols are well known in the art and have been standardized for both point-to-point protocol (MLPPP, also referred to as MP) and Frame Relay protocol (MLFR, also referred to as MFR), among others. Multilink protocols combine multiple physical or logical links and use them together as if they were one high-performance link. MLPPP is described in RFC 1717, which has been updated by RFC 1990. MLFR is described by specifications FRF.15 and FRF.16. (Note: If not otherwise stated herein, it is to be assumed that all patents, patent applications, patent publications and other publications (including web-based publications) mentioned and cited herein are hereby fully incorporated by reference herein as if set forth in their entirety herein.)
MLPPP and the MLFR Protocols function by fragmenting datagrams or frames and sending the fragments over different physical or logical links. Datagrams or frames received from any of the network layer protocols are first encapsulated into a modified version of the regular PPP (Point-to-Point Protocol) or FR (Frame Relay) frame. A decision is then made about how to transmit the datagram or frame over the multiple links. Each fragment is encapsulated and sent over one of the links.
On a receiving end, the fragments received from all of the links are reassembled into the original PPP or FR frame. That frame is then processed like any other PPP or FR frame, by inspecting the Protocol field and passing the frame to the appropriate network layer protocol.
The fragmenting of data in multilink protocols introduces a number of complexities that the protocols must be equipped to handle. For example, since fragments are being sent roughly concurrently, they must be identified by a sequence number to enable reassembly. Control information for identifying the first and last fragments must also be incorporated in the fragment headers. A special frame format is used for the fragments to carry this information.
One possible remedy for this would be to utilize the solution disclosed in U.S. Pat. No. 6,912,197 wherein the active and standby processors exchange messages to synchronize fragment numbers. The active processor sends periodic updates to the standby processor with a sequence number. On an activity switch, the newly active processor calculates a new sequence number as a sum of the number received from the previously active processor plus a jump number. The jump number is calculated as a maximum number of fragments that can be transmitted in a timeframe between the previous update and the switchover time.
There may be at least two drawbacks of this solution. The first is the burden of sending periodic messages between the processors. There may be hundreds and thousands of MLPPP groups supported on the switch processor. Sending periodic messages for all of them may be resource consuming. Another other drawback is that the jump count may vary since the fragment rate is not predictable. It will almost always be greater than the number expected by the receiver. The receiver at the other end of the network may have to unnecessarily wait for missing fragments that will never come in. This creates a delay in the fragment flow since the receiver must wait for “missing” fragments until a timeout expires.